home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001348_daemon _Fri Jun 18 12:09:25 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA25533; Fri, 18 Jun 93 12:09:28 MET DST
  3. Return-Path: <dsr@hplb.hpl.hp.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA25528; Fri, 18 Jun 93 12:09:25 MET DST
  6. Received: from mcsun.EU.net by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA11931; Fri, 18 Jun 1993 12:31:14 +0200
  8. Received: from hplb.hpl.hp.com by mcsun.EU.net with SMTP
  9.     id AA08107 (5.65b/CWI-2.225); Fri, 18 Jun 1993 12:31:11 +0200
  10. Received: from dragget.hpl.hp.com by hplb.hpl.hp.com; Fri, 18 Jun 93 11:23:11 +0100
  11. Received: by manuel.hpl.hp.com
  12.     (16.6/15.6+ISC) id AA29068; Fri, 18 Jun 93 11:29:22 +0100
  13. From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  14. Message-Id: <9306181029.AA29068@manuel.hpl.hp.com>
  15. Subject: re: HTML+ support for eqn & Postscript
  16. To: torben@hawaii.edu
  17. Date: Fri, 18 Jun 93 11:29:21 BST
  18. Cc: janssen@parc.xerox.com, www-talk@nxoc01.cern.ch
  19. Mailer: Elm [revision: 66.36.1.1]
  20.  
  21. >> [Dave's example of <EMBED> and eqn]
  22.  
  23. > Well, it may be the best that we're going to get. However, I still feel that
  24. > equations are too basic to not be supported directly. Note that the more
  25. > successful text processing systems (and that's part of what this will have to
  26. > be) all support text, equations and tables nicely.
  27.  
  28. The ability to embed foreign formats seems a good thing as it allows us to
  29. take advantage of evolving de facto standards for a whole range of things.
  30.  
  31. Just how critical is building in support for equations to the continuing
  32. growth of the web? IMHO long term success is more important than intellectual
  33. purity.
  34.  
  35. Some general issues:
  36.  
  37.     o   trade-off of complexity versus coverage
  38.  
  39.         ISO have an SGML DTD for maths - but this is "clearly" too complex.
  40.         Perhaps there is a reasonable middle ground which would satisfy
  41.         most peoples needs. Increasing the coverage from that point would
  42.         enormously add to the complexity. So what is the right coverage?
  43.  
  44.     o   the impact of yet another standard for equations
  45.  
  46.         A simple approach for equations (which is easy to convert to/from
  47.         existing standards) may be worthwhile if widely adopted ...
  48.  
  49.     o   the large numbers of math symbols in use
  50.  
  51.         A real problem this. Which ones are common place?
  52.  
  53.     o   just how much code is needed for parsing/rendering?
  54.  
  55.         Lets keep browsers simple!
  56.  
  57.     o   what to do with line mode displays
  58.  
  59.         Well you could just show the markup format ...
  60.  
  61. I will have a look at eqn and Latex to get a feeling for what would
  62. be involved in extending HTML+ to directly support equations, and how
  63. one could deal with it in browsers.
  64.  
  65. Dave Raggett